This section is intended to introduce the reader to various aspects of art, which may be related to various aspects of the present invention that are described and/or claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present invention. Accordingly, it should be understood that these statements are to be read in this light, and not as admissions of prior art.
Media delivery streaming solutions are mainly based on protocols such as Real time streaming Protocol (RTSP) as defined in the IETF RFC 2326, Microsoft Media Server (MMS) proprietary protocol from Microsoft or Real Time Messaging Protocol (RTMP) proprietary protocol from Adobe Systems.
More recently a streaming technique, that is adaptive and based on HTTP protocol, has emerged with different flavors such as the “Move Adaptive Stream” from Move Networks, the “HTTP Live Streaming” from Apple Inc. and the “IIS (Internet Information Services) Smooth Streaming” from Microsoft. The benefit of using the HTTP protocol in these streaming solutions is its capability to cross over NATs and firewalls seamlessly. The HTTP adaptive streaming technology provides a way to compensate for erratic network behavior regarding available bandwidth by continuously and gracefully upgrading or downgrading the video quality in order to fit with the bandwidth constraint.
In more detail-, WO 2005/109224 A2 from Move Networks describes a mechanism in an Agent Controller Module hosted in the client side and able to adapt to the fluctuant network bandwidth thanks to the fact that the media to stream is previously organized in a plurality of streamlets, also called chunks, each of them being encoded from low to high bitrates. According to the available network bandwidth and some other additional information a monitoring tool incorporated in the Agent Controller Module uses the HTTP protocol to request the server to send the best suited chunk to be streamed over a TCP/IP connection. On an elementary chunk basis the quality is up-shifted or down-shifted according to the Agent Controller Module.
WO 2009/020552 A1 from Move Networks discloses a system in which a client carries out a “parallel retrieval” method of more than one streamlet or part or streamlet at one time using multiple connections between the client and a single server.
The IIS Smooth Streaming Technical Overview, from Alex Zambelli, Microsoft Corporation, March 2009, describes the IIS Smooth Streaming Technique based on HTTP protocol over TCP/IP connection. The media to be streamed by the Server is previously chopped into chunks representing for example one to ten seconds duration. Then these chunks are encoded according to the H.264/MPEG-4 AVC standard at different bitrates and stored within a MP4 file format container. The mechanism selecting the bit rate according to the network bandwidth fluctuation and requesting seamlessly the corresponding chunks from the server is entirely implemented in the client side through an application code, the Silverlight application. The HTTP Live Streaming supports dynamic switching between streams of different data rates in response to changing connection speeds.
Apple Inc. submitted an Internet Draft to IETF in October 2009 on an HTTP streaming method specification entitled “HTTP Live Streaming draft-pantos-http-live-streaming-02”. The HTTP streaming architecture of Apple, Inc. is based on 3 pillars: a Server, a Distribution, through a Web server or a Web caching system, and a Client. The media to be streamed is a video encoded in H.264 and an audio encoded in AAC. At a server, media to be streamed is encapsulated in MPEG-TS containers and fragmented into chunks of equal duration with a specific tool named Apple stream segmenter. This tool generates the chunks that are saved into *.ts files and an index file *;m3u8 constituting the chunks playlist. Then a client fetches the index file first thanks to an URL pointer. The index file, in turn, specifies the location of the available media files, decryption keys, and any alternate streams available. For the selected stream, the client downloads each available media file in sequence.
HTTP adaptive streaming methods are generally oriented to adapting the media viewing experience of the end user according to network congestion. Indeed, as soon as the network bandwidth measured by the client device decreases, the latter requests chunks which are less restrictive with respect to network bandwidth requirement; the “low bandwidth chunks”. Conversely when the congestion problems decrease, the client device requests chunks which are more restrictive with respect to network bandwidth requirement; the “high bandwidth chunks”.
The FIG. 1a illustrates the main steps of adaptive streaming method according to prior art. FIG. 1a shows a video content has been (pre-) encoded into four versions (version A, version B, Version C and version D) with increasing supported bit rates implying progressive quality increase. The encoded video content is split into chunks that allow seamless switching from one bit rate to another. All the video chunks correspond to an identical fixed duration. These chunks are more or less big: thus requiring higher/lower bandwidth and providing better/lesser video quality, depending on the supported bit rates. All the versions of the content stored in the server CS1 (version A, version B, Version C and version D) are split into a fixed number of chunks, 14 chunks in the FIG. 1a. 
On FIG. 1a, a first step of the method according to prior art is shown: a client device CD monitors the bit rate BR1 of a path P1 connecting the client device CD to the server CS1.
In a second step, the client device CD determines a requested bit rate RBR compliant with the measured bit rate BR1. For example the requested bit rate RBR is the largest of supported bit rates BRA, BRB, BRC, BRD which is also less than or equal to the measured bit rate BR1.
In a third step, the client device requests via the path P1 a chunk identified by a time index i (here 1<i<14) and the requested bit rate RBR.
In a fourth step, the client device CD receives still from the path P1-chunk i at the requested bit rate RBR from the server CS1.
The four steps are repeated each time a chunk is needed.
The FIG. 1b shows a temporal evolution of the bit rate for a method of adaptive streaming of the prior art as presented above.
The curve on FIG. 1b shows the monitored bit rate BR1. Below the curve, one represents the chunk which is downloaded from the server. A typical adaptive client will continuously monitor the available bitrate (or bandwidth) and select the requested bit rate which is less than or equal to the available bit rate BR1 for the next chunks to be retrieved. Of course, depending on the implementation and the environment (network technology, application) the strategy may be conservative—i.e. the client requests higher bit rate chunk only after a certain time ensuring smooth upgrade transition; the client requests lower bit rate chunk as soon as it detects a bandwidth decrease implying rapid downgrade transition)—or more aggressive. In FIG. 1b, there are 4 different bit rates depicted corresponding to the four versions of the encoded content.
With the adaptive streaming solutions explained above, the video stream that is acquired by the client CD chunk after chunk does not have a consistent quality with time. It is understood that the user experience may be damaged when the bandwidth goes down. The video never or rarely interrupts but the quality could be very poor. There is no other particular solution to preclude this situation other than reducing the quality of transferred content. Increasing the receiver buffer will avoid the dry effect wherein a chunk delivery takes more time than expected but will not do anything against temporary low bandwidth availability.
One of the goals of the present invention is to fight the temporary lack of bandwidth (or bit rate quick slowdown) by using at least two (independent) delivery paths both being controlled by the client. These delivery paths must present transmission characteristics as orthogonal as possible. This can be achieved having one client (e.g. a terminal) connected to a server via at least two different access networks (e.g. broadband xDSL and cellular 3G/LTE) or/and connected to a server connected to at least two similar access networks (possibly managed by two different internet service providers) or this can be realized by having one client connected to at least, two servers, each server being connected to a different access network. The latter may be easier to implement and we will focus on this implementation for the invention. In the rest of the document a server can be viewed as a physical box connected to a dedicated link/path or as a logical entity connected through a dedicated path/link as well.
It is understood that the invention applies when at least two links/paths. In case of one machine hosting logical servers, the machine must support multi homing (i.e. can be connected to more than one network interface, each having a dedicated—e.g. IP-network address).
Instead of having the chunk files stored on one server, they are stored on two servers accessible through two different communication paths (each server has its own network accesses and its own IP address).
When the client detects that the available bit rate is slowing down on one of the paths, it can download the next chunk, or the next part of the chunk, from the alternative server. This can be implemented through a failover algorithm (use one main path and use the alternative path when the main path is struggling), through a load sharing algorithm (use both paths concurrently: a chunk is delivered partly from one of the server and partly from the other server or even through a bandwidth limited algorithm (guarantying a minimum global bit rate, by a main path P1 and additional paths P2, P3 in case an additional bit rate is needed to fulfill the global bit rate objective).